1. Field of the Invention
The present invention is directed generally to systems and methods related to computer-aided design (CAD) software, and more specifically to such systems and methods of providing engineering, construction, and operations CAD software application services over the Internet.
2. Related Art
CAD software is well known, and is used by architects, engineers, artists, and the like to create precision drawings and technical illustrations. CAD software is used to create two-dimensional (2-D) drawings and three-dimensional (3-D) models. Applications such as, e.g., MicroStation™ products, which are developed by Bentley Systems, Inc., Exton, Pa. U.S.A., and AutoCAD® products, which are developed by Autodesk, Inc., San Rafael, Calif., U.S.A., are typical of such CAD software, which may be used in the engineering, construction, and operations (ECO) marketplace. Also illustrative of the systems and methods used in the ECO marketplace are: U.S. Pat. No. 5,815,415 for a “Computer System for Portable Persistent Modeling”; U.S. Pat. No. 5,987,242 for an “Object-Oriented Computerized Modeling System”; and co-pending U.S. Ser. No. 09/296,738, filed Apr. 22, 1999, for a “System for Collaborative Engineering Using Component and File-Oriented Tools”, each of which is commonly assigned to the assignee of the present invention, and is incorporated herein by reference.
Heretofore in the ECO marketplace, CAD software has most typically been used in one of two scenarios. Small- to medium-sized businesses, on the one hand, have deployed solutions such as AutoCAD in a standalone or networked environment. On the other hand, large, multinational businesses in the architectural, engineering, and construction (AEC) industries have deployed far-flung networks of robust solutions such as MicroStation. The relative costs of these solutions vary widely, depending in large part on the size and scalability of the projects in which they will be used. Nevertheless, the costs of these solutions represent but a small portion of the money spent in the ECO marketplace.
Every constructed asset has a life cycle of engineering, construction, and operations, which involves multiple disciplines (e.g., contractors, consultants, and subcontractors). Both unique in its design and uniquely located, each project typically requires a complex network of professionals and trades, which are themselves a unique gathering for each project. The supply chain for constructed assets is, therefore, enormous. As a result, managing that supply chain is an enormous task.
It has been found that as much as sixty percent of the nearly $3.6 trillion spent each year for construction goes to labor and not materials. Of course, the various trades account for most of this. However, it turns out that $30 billion is spent each year for design professionals to generate nearly eight million engineering drawings. An even greater amount of time and money is spent in finding and interpreting information embedded in those engineering drawings. Accordingly, it should be readily appreciated that engineering drawings are an essential technology of information integration in the ECO marketplace. It would be highly desirable, therefore, to provide CAD software for the ECO marketplace that reduces the time and money spent to generate engineering drawings, as well as finding and interpreting information embedded in those engineering drawings.
One approach that has been used in the past to simplify the processes of generating, finding, and interpreting engineering drawings has been to deploy CAD software over a project “extranet.” Such project extranets help to automate the first (i.e., planning) stage of construction by removing inefficiencies of communications and coordination. Nevertheless, improvement of the first-stage design communications costs eventually reaches a point of diminishing returns.
It has been tempting in the past to suggest that the next step for improving management of construction projects would be to have everyone involved in a project concurrently online, in real time. However simple this suggestion might be, it ignores the real nature of the work being done. The many-varied workgroups in a design/construction value chain require absolute stability, with well-defined points of departure. For example, design, procurement, and installation of a typical heating, ventilation, and air conditioning system not only takes time, but also cooperation. “Long-transaction” commerce considerations come into play. Unfortunately, conventional asset engineering systems and methods have simply overlooked the need to provide essentials such as change merging, integrity checking, and versioning.
What has been lacking in most such systems and methods is “straight-through” processing. In straight-through processing, information captured at every step is encapsulated. Any element of information, once created, can be uniquely identified and re-used in subsequent transactions. With constructed-asset supply chains, however, attempts to use similar such processes have more often than not been thwarted by the opaqueness of monolithic CAD files, where the smallest negotiable unit of information is the drawing. Trained professionals can painstakingly interpret drawings, in their full context, but conventional systems and methods have been unable to penetrate conventional drawings and extract useful data. Moreover, the common practice in such systems is to transmit those drawings as raster files. It would be desirable, therefore, to provide a system and method which overcomes these obstacles.
Beyond the problems noted above, conventional systems also have suffered from two additional problems. Systems such as AutoCAD are relatively inexpensive. However, they are generally not sufficiently scalable to be used in large and complex projects, and regardless of their relatively low cost, inaccessible to many in the construction trades who are averse to computers. It would also be desirable, therefore, to provide CAD software which would not only be relatively inexpensive, but also scalable, robust, and easy-to-use.
A more recent attempt to achieve these goals has been the deployment of “project hosting” by application service providers (ASPs), such as ProjectPoint by buzzsaw.com. ASPs, in general, provide a contractual service offering to deploy, host, manage, and rent access to an application from a centrally managed facility. ASPs are responsible for either directly or indirectly providing all of the specific activities and expertise aimed at managing a specialized software application or set of applications. However, ASPs such as buzzsaw.com face a significant disadvantage. Their websites are most often run from a library of static pages, which are created in Hypertext Markup Language (HTML) under control of ActiveX™ (developed by Microsoft Corporation, Redmond, Wash. U.S.A).
HTML is perhaps the most portable of today's markup languages. It is supported by over 100 million Web browsers, and has become the de facto standard for transmitting information between people. HTML has many advantages, not the least of which is that HTML browsers are typically free. They are very powerful, have a combination of third-party add-ins and server-side content support, and a vast range of information is being delivered to HTML browsers. HTML document browser interfaces are easy to build into existing products because of the simplicity of HTML. HTML is easy to learn because it is very simple. There are only a couple dozen tags, but less than half of them are used in most situations. In working with HTML for just a few years, it has become very evident to users that the hypertext model really does work across systems that are otherwise unrelated. Any page can link to any other publicly accessible page simply by entering the address. There are some specialized structures in HTML, but the structures are mostly used to effect a certain formatting look. Because of the simplicity and low cost of HTML, a huge information base has been formed that makes HTML even more valuable.
HTML's simplicity, while making it valuable as a basic way of delivering simply structured information, causes it to fall short of being a long-term method of delivering complex information types. HTML is a very weak presentation tool that lacks even the most fundamental page-oriented formatting capabilities, such as, e.g., hanging indents, white-space control, justification, kerning, and hyphenation. HTML does not handle multiple-column snaking very well, either. However, because of the nearly universal compatibility, web site designers are getting around these problems by using tables to fake multiple columns and indents, GIF graphics to create certain designs with type and white space, and other such machinations. In such cases, HTML itself has simply become a shell that contains the real markup.
HTML is also a weak markup tool, because it does not allow for creating custom tags or presenting tags with different styles. There is no real modularity or hierarchical relationships between elements. This limits HTML to delivering page-oriented information instead of being a method to deliver intelligent information. HTML provides linking capabilities, but the linking is rudimentary; it is only a one-to-one link, and requires an anchor on the target end in order to access anything within the document. This is fine for most purposes, but such simple linking capabilities will limit HTML's long-term viability.
Another major problem with HTML is its instability. First, there was HTML, then HTML+, then HTML 2, then a series of decimal-point specifications in the threes, and now a level-4 HTML. Browser manufacturers have also created extensions to the “standard” HTML, like the “blink” and “center” tags. This has caused other browser manufacturers to play “catch-up”. The combination of this instability and HTML's simplicity has caused a situation where there are numerous codes that break when presented in a browser. The presence of “Best Viewed with Microsoft Internet Explorer”, or “Optimized for Netscape” banners attests to the fact that a page has been crafted to work best with a particular browser, at the expense of all of the others.
This balkanization of HTML has made webmasters and users frustrated and looking for a better solution. One way the HTML keepers are trying to extend HTML is by providing the ability to create more customized styles, while keeping the same markup. This is being done by cascading style sheets (CSS), which is a technical recommendation by the W3C (World Wide Web Consortium). CSS separates structure (i.e., HTML markup) from format (i.e., how it looks). While this is a good step, users are still stuck with the basic HTML tag set.
HTML's predecessor, the Standard Generalized Markup Language (SGML), is an international standard that is more than ten years old. It was originally designed to provide a way of describing text-based information so organizations could interchange information easily. Since then, SGML has become valuable in describing information sets so companies can get beyond the restrictions of paper-only publishing. SGML provides a way of creating markup languages customized for each document type, and separating the content from eventual formatting.
SGML is not tied to a particular operating system or application, and so it is portable from platform to platform. It is a standard maintained by the International Standards Organization (ISO). This means that it is very stable and while there are provisions for updating and changing ISO standards, the organization makes it very difficult to do so. This has turned out to be a real advantage, since it provides companies with a known syntax.
Because of the standing of SGML as a stable standard, there are many products available in every category, from editors to document management solutions, to typesetting and web delivery applications. Many vendors are providing tools and support in each category. These products range in price from free to very expensive. Since SGML is platform independent, these tools can be mixed and matched as desired, relieving companies of the risk of having their information locked into one vendor's product. SGML does not provide a fixed set of tags, but, rather, a syntax for creating your own tags. Many industries have formed consortia for the purpose of creating common tag sets to interchange information using their terms and expressions.
Notwithstanding its many advantages, SGML is complicated to understand and difficult to integrate into an application. SGML requires a “parser”, which is difficult to write and maintain. Since SGML was created in the early days of desktop computers, it is overly concerned with maximizing limited memory and disk space by providing a complex set of “minimization” rules and exceptions. This complexity results in SGML being more expensive than a simple tag set like HTML. Each document must have a “document type definition” created, which requires the owner of the document to perform a “document analysis” to discover its structure. Also, because of the complexity of the standard, and the smaller market for vendors, tools that support SGML are more expensive than those that support HTML.
Another document format, the “portable document format” (PDF), was developed by Adobe Systems Inc., in order to provide a system-independent way of delivering page-based information. PDF files are created by printing to a PDF driver or by so-called “distilling” a PostScript file. The resulting PDF file can be read using a tool from Adobe called “Acrobat Reader,” which is freely available on most popular systems in use today.
PDF provides electronic pages with impressive page fidelity. Type, graphics, and color are all reproduced as they are on paper. Even hot links and other electronic object types, like movies and sounds, can be added to a PDF file. PDF files are inexpensive to create, and are used by many companies to deliver page-formatted information without the high cost of postage. Since the end user gets something that looks very much like paper, training costs are low.
However, PDF creates large files with little structural information. PDF files are not nearly as flexible as other electronic formats because the main goal is to recreate a paper page, and not to provide a way of delivering intelligent document structure to a user. There is also little support for searching, although Adobe has other products that can index many different PDF files for cross-document searching and navigating (i.e., “turning” pages, “flipping” from section to section, and “scanning” the page for text of interest). Other than this limited support, navigation is limited. Another problem is page fidelity. PDF pages are not necessarily pixel-by-pixel replicas of a page that might be printed by the owner of the document. This is partly due to the fact that the fonts which are used to create the document originally might not be on the machine that eventually views the document. It was found desirable, therefore, to come up with a solution having the low cost and simplicity of HTML, the power and flexibility of SGML, and the pleasing formatting capabilities of PDF. Proponents of the “Extensible Markup Language” or XML, believe that standard fits the bill.
Just as in HTML, XML makes use of “tags” (i.e., words bracketed by “<” and “>”) and attributes (of the form, e.g., name=“value”). However, while HTML specifies what each tag and attribute means, and often how the text between them will look in a browser, XML uses the tags only to delimit pieces of data, and leaves the interpretation of the data completely to the application that reads it. In other words, if one sees “<p>” in an XML file, one should not assume it to be a paragraph. Depending on the context, it may be a price, a parameter, a person, etc. One distinct advantage of XML, furthermore, is its extensibility. For example, industry organizations such as the International Alliance for Interoperability have promoted such standards as aecXML™ (a trademark of the aecXML Domain).
aecXML is a framework for using the XML standard for electronic communications in the architectural, engineering and construction (aec) industries. It includes an XML schema to describe information specific to the information exchanges between participants involved in designing, constructing and operating buildings, plants, infrastructure and facilities. Various software applications used by aecXML participants can transfer messages formatted according to the aecXML schema to coordinate and synchronize related project information. Additionally, its specification facilitates e-commerce between suppliers and purchasers of equipment, materials, supplies, parts and services based on that same technical information. It would also be desirable, therefore, to provide CAD software usable over the Internet by way of dynamically rendered web pages using an extensible markup language, such as XML.
Another significant drawback to project hosting websites such as Project Point is that they are limited to proprietary drawing file formats created by AutoCAD (e.g., the DWG and DWF file formats). As a result, all of the users accessing such websites must run AutoCAD, or they will not be able to participate in the project. It would, therefore, be desirable to provide CAD software for an Internet environment, which is flexible and adapted to multiple drawing file formats. DWF files, for example, suffer from the disadvantage that they remove the nonvisual components of a drawing, such as attributes, properties, and complex object behavior. Moreover, the DWG format is an electronic plot that is view only, so that no matter how many people access the document, the integrity of the design is preserved. DWF files support hyperlinks, and such hyperlinks are usually not limited to data files. They can also activate Java applications, scripts, or other DWF files.
Most of the software that is used in engineering workflows today, including MicroStation and AutoCAD, generate project information in the form of files. The data contained in these files is very important to the engineering enterprise. Accordingly, efficient management and maintenance of such data has become of paramount concern. Most of the CAD applications in use today, as well as the operating systems that run them, allow only single-user access to each file. As a result, there is contention for write access which has greatly influenced today's engineering workflows. Certain data management tools are available, but the granularity of the data still remains at the file level. It would be highly desirable, therefore, to provide a system that would allow engineering project data to be stored and managed at the component level to open up a number of workflow improvements.
Component-level information management enhances the granularity of project data from files to components. Drawing files, such as DWG files and DGN files can be stored as a series of components. As a result, project data is available at a more granular level. Such component-based organization, thus, makes it possible to access information on a per-file basis, but manage change on a per-component basis. In short, that means that more than one person can edit a file at the same time. The MicroStation concept of reference files can, therefore, be extended into “shared” files where all users can edit project data at any time.
Component-level information management journals project changes and provide a reliable project history. When a set of components is changed in a MicroStation editing session, it is called a transaction. This transaction becomes a necessary process in managing DGN data at a component level. The transaction management process provides a “journal” of changes to the components. By “looking back” through the journal, users can access project data as it existed at previous stages of development. This concept of a complete project history, thus, becomes a valuable tool for project managers to understand how, when, by whom and why decisions were made, and if needed, reverse them.
Component-level information management leads to better coordination of hybrid projects. That is, the concepts of component-level information management apply not only to MicroStation, but also to other types of engineering files (e.g., those created by AutoCAD. AutoCAD-specific workflows will, thus, gain the same benefits of simultaneous write access and project history as do MicroStation workflows. In addition, since many engineering projects involve hybrid data sources, and an amalgamation of both AutoCAD DWG and MicroStation DGN files in the same project, the concepts of component-level information management will allow these hybrid file formats (and, in turn, hybrid workflows) to come together in one efficient and coordinated environment.
Conventional project oriented CAD systems and methods only provide textual based information regarding projects, people and businesses. Such textual information is difficult to analyze. It is desirable that a more user-friendly, graphical display means be used to convey the project-oriented data information. For example, conventional CAD systems lack geospatial visualization tools or geographic information system (GIS) viewing functionality.
A GIS combines layers of information about a geographic location to provide an analyst a better understanding of that place. What layers of information are combined depends on the GIS analyst's purpose, such as, e.g., finding the best location for a new store, analyzing environmental damage, viewing similar crimes in a city to detect a pattern, and so on. A GIS can include mapping software that links information about where physical things are with information about what the physical things are like. Unlike with a paper map, where “what you see is what you get,” a GIS map combines many layers of information.
A conventional paper map enables a user to view a pictorial representation of, e.g., cities, roads, mountains, rivers, railroads and political boundaries. For example, conventionally, cities can be represented by little dots or circles, a road by a black line, a mountain peak by a triangle, and a lake by a blue area.
Similarly to the conventional paper map, a digital map created by a GIS can have dots, or points, representing features on the map such as cities. Lines can also represent features such as roads. Small areas can similarly represent features such as lakes. A significant difference between the digital map and the conventional paper map is that the information used to generate the digital map comes from a computer database of information. The data is shown only if the user chooses to show it. The data can be selectively layered and viewed. The database can store, e.g., where the point is located, how long the road is, and even how many square miles a lake occupies.
Each piece of information in the map sits on a layer, and the users can turn on or turn off the layers according to their needs. One layer could be made up of all the roads in an area. Another could represent all the cities. Yet another could represent all the lakes in the same area.
Conventional GIS systems include, e.g., the ArcInfo family of products from Environmental Systems Research Institute (ESRI) of Redlands, Calif., and MapInfo available from MapInfo of Troy, N.Y. Unfortunately, conventional GIS systems are standalone database systems. Conventional GIS systems run on a standalone workstation. Unfortunately, conventional GIS systems do not include web-based collaboration systems and methods.
Conventional browser-based project oriented collaboration systems do not include any geospatial analysis functionality or viewing capabilities. Instead these browser-based collaboration systems only provide for viewing of project information in a textual form. What is needed then is an improved browser-based project oriented collaboration system and method that overcomes the shortcomings of conventional systems.